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second fulfillment server 16 can be designed to communicate to its LFMs 22 and/or 
ATP servers 14 so as to minimize and balance the processing load placed upon each 
of those LFMs 22 and/or ATP servers 14. Alternatively, the various LFMs 22 and/or 
ATP servers 14 may be given different time slices of the horizon to handle, and 
5 component quotations 34 may be broken down and staged accordingly. This may 
increase latency to optimize scalability with respect to size and throughput. 

In one embodiment, the components of system 10 use a protocol referred to as 
"Request-Promise- Accept" (RPA) in creating, managing, and fulfilling ATP requests 
relating to products. In general, according to the RPA protocol, a customer requests 

10 one or more products and a supplier offers a promise that meets the requirements of 
the customer request as closely as possible. Upon reviewing the offered commitment 
from the supplier, the customer either accepts or rejects the promise. If the customer 
accepts the promise, both customer and supplier generally consider this acceptance to 
form a binding agreement. In certain situations, a customer cannot freely cancel an 

15 acceptance within a specified time interval because of this commitment. The RPA 
protocol was developed as the basis for managing supply and demand requests 
between autonomous planning domains of a distributed supply chain as part of the 
RHYTHM supply chain planner (SCP) engine from i2 TECHNOLOGIES, INC. In 
another embodiment, fulfillment server 16 may use business rules to examine a 

20 supplier quotation or promise and determine if it meets the requirements of the 
customer. Based on that determination, fulfillment server 16 may either accept or 
reject the quotation or promise. In addition, fulfillment server 16 may allow a LFM 
22, ATP server 14 ? or other supplier system to withdraw a component quotation. For 
example, a supplier may lose a source of raw materials for one of its products, and the 

25 supplier may take steps to withdraw any quotations involving that product. The 
ability to withdraw a quotation may depend on the status of the quotation. For 
example, a supplier may be unable to withdraw a quotation that has been accepted by 
a client 12. 

Although FIGURE 1 illustrates one example embodiment of system 10, 
30 various changes may be made to system 10 without departing from the scope of the 
present invention. For example, FIGURE 1 illustrates fulfillment server 16 as being 
separate from clients 12, ATP servers 14, and LFMs 22. In another embodiment, 
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fulfillment server 16 may be combined with a client 12, an ATP server 14, and/or a 
LFM 22. Also, the logic used by LFM 22 to perform its described operations may be 
performed by a client 12, ATP server 14, or fulfillment server 16. As particular 
examples, the logic of LFM 22 could be executed by a procurement management 
5 system of a client 12 or an order entry system of a supplier. Further, system 10 could 
be given only limited access to the availability information of a supplier. For 
example, a supplier may only store a portion of its availability information in ATP 
server 14, and/or LFM 22 could be given only limited access privileges to the 
information in ATP server 14. This would allow, for example, a supplier to sell a 
10 portion of its products using system 10 and sell the remaining portion of its products 
through other sales mechanisms. 

FIGURES 2 through 5 illustrate the operation of system 10 through a series of 
workflows. These and other described workflows involve an interactive scenario with 
full use of the extended RPA protocol according to the present invention. However, 
15 not all workflows need to be interactive and not all result in Ml use of the extended 
RPA protocol. For example only and not by way of limitation, large companies may 
often process the bulk of their customer orders using EDI based techniques, in which 
an ATP request results in an ATP-consuming promise without further customer 
interaction. Those skilled in the art will appreciate that system 10 accommodates 
20 EDI-based and other suitable workflows, and that the present invention is intended to 
encompass all such workflows and associated operations. Also, the following 
descriptions describe fulfillment server 16 communicating with an ATP server 14 
through a LFM 22. As described above, LFM 22 could maintain a local or other 
database and is not required to use an associated ATP server 14. In this embodiment, 
25 the functions described below as being performed by ATP server 14 may be 
performed by LFM 22, and the functions described below as being performed by 
LFM 22 to facilitate communication with ATP server 14 may or may not be needed. 

ATP Request Workflow 

30 FIGURE 2 illustrates an example ATP request workflow in which a multiple 

line-item ATP request 30 is created at client 12, client 12 submits ATP request 30 to 
fulfillment server 16, and fulfillment server 16 brokers ATP request 30 against one or 
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more LFMs 22 and/or ATP servers 14 in the form of component ATP requests 32. 
These LFMs 22 and/or ATP servers 14 process component ATP requests 32, generate 
resulting component quotations 34, and send the component quotations 34 to 
fulfillment server 16. Fulfillment server 16 processes the component quotations 34 
5 and generates a unified quotation 36, which is sent to client 12 for review. 

Initiate ATP Request [Client] 

In one embodiment, to initiate ATP request 30, client 12 or an associated user 
may be required to provide appropriate identification and security information. Client 

10 12 may support default business rules or other constraints according to a user profile, 
a customer profile, or other suitable definitions. When the user accesses an ATP 
request screen associated with client 12, the screen may be populated with default 
parameters according to such definitions. The user may then optionally adjust some 
or all of these parameters to suit the needs of the particular ATP request 30. Such 

15 parameters may include shipping requirements, preferences with respect to product 
sourcing, product alternates or substitutions, ship-to location, price targets, and any 
other appropriate parameters. The parameters may also include attributes of the 
requested item. For example, a request 30 may specify the desired model, color, and 
engine of an automobile. In a particular embodiment, client 12 may specify that some 

20 or all of the attributes are mandatory. Client 12 could also submit values identifying 
the importance or desirability of each of the attributes of the requested product. 

In one embodiment, the user may select a product from a table of available 
products, organized according to product group or in another suitable manner, using a 
product catalog, search engine, or otherwise. A catalog could, for example, include 

25 products from all suppliers in system 10. The catalog could also include a search 
engine allowing a user to locate desired products. In a particular embodiment, the 
search engine may support attribute-based searches that match attributes of products 
with attributes supplied by a user. A catalog could reside within fulfillment server 16, 
or fulfillment server 16 may communicate with an external catalog or order 

30 management system to support catalog functions in system 10. In a particular 
embodiment, fulfillment server 16 maintains a model of the items and suppliers in the 
marketplace, and changes to an external catalog may be replicated in fulfillment 



